Creating the delivery service and MDC applications

Pega Academy provides an opportunity for you to practice what you learn.

Pega Academy provides two different exercise systems for you to complete the exercises:

1. Cloud instance (online)
2. Virtual Machine (VM) (offline)

The cloud instance (when available) is accessible by clicking Initialize Pega instance for this Challenge in the Scenario section.

The VM is made available as an Open Virtualization Archive (OVA) file that contains a compressed, "installable" version of a virtual machine.  

You can use any VM Player of your choosing, such as Virtual Box (Windows, macOS), VMWare Player (Windows), or VMware Fusion (macOS). You are responsible for downloading and installing your own VM player.

Exercise VM archive

The exercise VM is available as an OVA file that contains a compressed, "installable" version of a virtual machine. You can download the VM .ova file by using the following link:

LinuxLite-Pega231.ova 

The OVA file is approximately 7.5 GB and can take a while to download. Because of the large file size, the best practice is to use Chrome or Mozilla to complete the download.

Review the Pega Virtual Machine User Guide for crucial information on configuring the exercise VM correctly. Visit the respective website to access instructions on the latest version of the user guide.

Use your virtualization software (VM Player) to open, import, and extract the OVA file.

Although Pega does not provide a VM Player for you to use, use one the following recommended players:

• Virtual Box (Windows, macOS)
• VMWare Player (Windows)
• VMware Fusion (macOS)

The VM User Guide provides details on downloading and importing the OVA file and running the VM in one of the recommended VM players. You are responsible for downloading and installing your own VM player.

You must import the MDC Delivery Service solution RAP file provided into your Pega Platform instance after you install the Linux-Lite VM. To enable all operator IDs during the import of the RAP file, select the Enable advanced mode to provide more granular control over the import process and Enable new operators and overwrite existing operators on import options.

After analysis of the requirements for the Delivery Service application, the following conclusions are reached:

• Separate individual Case Types are required to handle processes related to Business partner registration, Renewal, Truck vendor registration, Delivery request, Truck request, and Invoice.
• A parent-child Case relationship is a better approach for handling the truck vendor enrollment and approval by different city managers in parallel.

The PegaRULES application contains a class group named PegaSample. The purpose of this class group is to demonstrate the features and capabilities of Pega Platform. The number of records associated with the PegaSample class group is minimal relative to the rest of the PegaRULES application. Nevertheless, a production application never uses PegaSample records. The PegaSample application might be packaged as a separate application built on PegaRULES.

An enterprise application does not need to contain Case Types. The main purpose of the enterprise application is to provide a standardized business object Data Model and other reusable record types, such as Libraries. This description describes the MDC Enterprise application, which, in theory, MDC’s Center of Excellence (COE) group maintains. The MDC application itself does not include any Case Types.

Any application created with the New Application wizard contains a work pool class and class group. The New Application wizard outputs classes with ORG-APP-[Data/Work/Int/UIPages/Link] and ORG-[Data/Int]. The New Application wizard also creates an ORG-FW abstract class regardless of choosing Framework, which you can ignore if not used.

Like the way PegaRULES uses PegaSample, an enterprise application should offer a way to test and demonstrate the features that it contains. Like PegaRULES, an enterprise application does not need to include test and demonstration records within its application. Instead, a test and demonstration application can be built on the enterprise application; this raises the question: how is the enterprise application constructed?

The MDC Enterprise application is constructed by creating a delivery service application with the New Application wizard. The initial application contains the four Rulesets listed in the Delivery Service App BEFORE column of the following table:

A copy of the Delivery service application is then saved as MDC to the MDC Ruleset. The MDC and MDCInt Rulesets are then removed from the Ruleset stack of the Delivery service application in its definition by the Lead System Architect. In place of the removed Rulesets, the delivery service application declares the MDC application as a built-on application. The MDC application removes the delivery service and delivery service Int Rulesets from its Ruleset stack.

A few changes are necessary to make the MDC application valid, starting with selecting an available skin Rule, such as the generic application skin or another MDC organization-level skin. Also, in the Associated Classes section of the Cases and Data tab, the class requires an update to reference valid classes. For example, in the case of the MDC application, the referenced classes must be MDC-specific because every ORG class extends Work-Cover-. The MDC class can be declared a class group so that the App Explorer displays the MDC class. Finally, edit the Application Wizard tab to advertise that the MDC application is for use as a built-on application.

For consistency, the validation mode of the MDC and MDCInt Rulesets uses Application Validation instead of Ruleset Validation, as shown in the following figure. This option provides more control over which versions of the MDC Rulesets are in use by other applications at any given time.

The application team will build the delivery service application on the truck service, truck request, delivery request, registration, and invoice applications.

The application team has decided to develop their application with a highly modular approach, which facilitates speedier development because more coding can occur in parallel. Additionally, the delivery services team wants to refrain from refactoring their application in the future to decompose one or more child Cases into reusable component applications. Smaller applications are more flexible and easier to maintain and deploy. This strategy is similar to the microservices strategy, which avoids monolithic applications.

Every Case Type defined within a built-on application requires extension through direct inheritance to develop and test the delivery service application. Each Case Type forms the built-on applications, and the team imports them into a separate Ruleset in the delivery service application. Afterward, the direct inheritance of the generated Case Type class changes to the class of its corresponding Case Type of the built-on application.

Case Type editing must occur within the built-on applications. This technique avoids the problem of editing two applications simultaneously, where Rules can end up in the wrong layer and the wrong Ruleset.

This approach works well for the delivery service team, who are pleased with the result. As is often the case, several Rules deemed unnecessary or obsolete are withdrawn during development. A major skim is performed on every Ruleset to remove those unnecessary or obsolete rules.